INTCOM.00 1 A PATENT 
SECURE ELECTRONIC PAYMENT MESSAGING SYSTEM WITH 
RECONCILABLE FINALITY 



Background of the Invention 

Related Applications 

[0001] This application claims priority under 35 U.S.C. § 119(e) from 

Provisional Application No. 60/417,697, filed on October 10, 2002, the entirety of which is 
hereby incorporated by reference. 

Field of the Invention 

[0002] The present invention relates to electronic payment systems and more 

particularly, to systems for allowing the secure execution of business-to-business, business- 
to-bank and bank-to-bank transactions with real-time finality of transactions. 

Description of the Related Art 

[0003] Electronic banking systems provide the convenience of transacting with 
banks or other financial institutions without the need to have some form of physical access to 
the bank or one of its branch offices. In non-electronic banking, this physical access could be 
by having a customer travel to a bank or branch office in person, by physically mailing or 
otherwise delivering a payment instrument of some kind (e.g., a check) to the bank or branch 
office, or by some other physical manifestation of an intent to initiate a financial transaction 
with the bank holding an account for the customer. These physical, non-electronic 
transactions were once standard for interactions between a bank and its customers. 

[0004] For transactions between banks or other financial institutions, there have 
been various electronic banking systems used in order to expedite the large-scale and high- 
volume transactions needed in order for banks to function effectively. However, such 
systems may not be available or effective for transactions between bank customers, even 
large commercial customers, and their banks. 

[0005] In addition, many electronic banking systems impose delays or the 
requirement for one or more trusted intermediary financial institutions in order to provide 
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effective resolution to electronic banking transactions. Such requirements introduce 
undesirable overhead into banking transactions. 

[0006] Therefore, there is a continued need for improved systems and techniques 
for electronic banking in order to improve the speed and efficiency of electronic banking, 
particularly for commercial transactions. 

Summary of the Invention 

[0007] In one aspect of the techniques described herein, a method for finalizing an 
electronic fund transfer that is matched to an invoice for is presented. The payment is to be 
made from a first party having a financial account at a first bank to a second party having a 
financial account at a second bank. The transaction is conducted using a network transfer 
system that is in electronic communication with the first party, the second party, the first 
bank and the second bank. 

[0008] In a further aspect of the technique, the step of generating at the first party 
a document which authorizes the payment of the invoice is performed. This document is 
signed using a first digital certificate in accordance with the procedure of a certificate 
authority in electronic communication with the transfer network system. 

[0009] In another aspect of the technique, the signed digital is sent from the 

first party to the network transfer system electronically, and may be authenticated via the 
certificate authority to demonstrate the authority of the signer of the signed document to 
assent to payment of the invoice. 

[0010] In another further aspect of the system, a copy of the signed digital 

document may be stored in a database associated with the transfer network system; 

[0011] For purposes of summarizing, certain aspects, advantages and novel 
features have been described herein. It is to be understood that not necessarily all. such 
advantages may be achieved in accordance with any particular embodiment. Thus, the 
systems described may be embodied or carried out in a manner that achieves or optimizes one 
advantage or group of advantages as taught herein without necessarily achieving other 
advantages as may be taught or suggested herein. 
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Brief Description of the Drawings 
[0012] The above mentioned and other features will now be described with 
reference to the drawings of the present securement system. The shown embodiments are 
intended to illustrate, but not to limit the invention. The drawings contain the following 
figures: 

[0013] Figure 1 schematically illustrates an overview of one embodiment of a 
system for providing secure electronic payment with reconcilable finality; 

[0014] Figure 1A illustrates an* alternate schematic arrangement for the 
components illustrated in Figure 1 ; 

[0015] Figure 2 illustrates a schematic representation of the ICN system of Figure 

l; 

[0016] Figure 3 illustrates a schematic representation of the ICN client of Figure 

i; 

[0017] Figure 4 is a process diagram for a message creation process; 
[0018] Figure 5 is a process diagram for a message send process; 
[0019] Figure 6 is a process diagram for a message receive process; 
[0020] Figure 7 is a process diagram for a message approval process; 
[0021] Figure 8 is a process diagram for a message reject process; 
[0022] Figure 9 is a process diagram for a process for rejecting an approved 
message; 
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[0033] Figure 20 is a process diagram for a payment rejected by the payee's bank; 

[0034] Figure 21 is a process diagram for a payment rejected by the supplier; 

[0035] Figure 22 is a process diagram for a payment rejected by the supplier; 

[0036] Figure 23 is a process diagram for an authentication process; 

[0037] Figure 24 is a process diagram for an order placement process; 

[0038] Figure 25 is a process diagram for an invoice payment process; and 

[0039] Figure 26 is a process diagram for an invoice payment process. 

Detailed Description of the Preferred Embodiment 
[0040] The following description and figures describing the preferred 
embodiments are made to demonstrate various configurations of possible systems and 
techniques in accordance with the current invention. It is not intended to limit the disclosed 
concepts to the specified embodiments. In addition, various systems will be described in the 
context of a networked computer system for carrying out the described techniques and 
methods. 

[0041] Those of skill in the art will recognize that the techniques described are 
neither limited to any particular type of computer or network, nor to the use of any particular 
hardware or software for every described aspect beyond the system itself. However the level 
of confidence to be given to the execution of transactions will depend on the compliance of 
some of the hardware platform to be used for ID, integrity and confidentiality management to 
specific level of security standards. It will be understood that a variety of hardware platforms 
meeting that standard may be used to implement the systems and techniques described herein. 

[0042] To facilitate a complete understanding of the invention, the remainder of 
the detailed description describes the invention with reference to the Figures, wherein like 
elements are referenced with like numerals throughout. 

Overview 

[0043] A transfer network system 100 for providing communications between 
commercial buyers 110 and suppliers 120 and their respective banks 130, 140 is illustrated in 
Figure 1. This transfer network system, also referred to interchangeably herein as an 



Intercomputer Network, or ICN is a system which is can be used to mediate and facilitate the 
real-time electronic banking transaction between a buyer and a supplier. 

[0044] As shown in Figure 1, a buyer 110 may be a corporation or other entity 
that is going to be involved in purchasing some goods or services from the supplier 120, also 
referred to as a seller. As the Figure shows, both the buyer and the supplier may have a 
number of business functions which are normally involved in a transaction between two 
businesses. In small companies, these functions may performed by the same individual 
within the company. For instance, purchasing and accounts payable functions may both rest 
with the same person at a small company. In a larger company, it would not be uncommon 
for these functions to be handled by separate people, or even separate departments. Similarly, 
the business functions of the supplier may be handled by one or more individuals as 
appropriate, to the size and structure of the supplier. 

[0045] In one embodiment of the described system, both the buyer 110 and the 
supplier 120 are connected to the ICN 100 via a communications medium 125, represented 
by the arrows in Figure 1 . Most typically, this connection is by both the buyer and supplier 
having an appropriate ICN client which is connected to the internet. The ICN system is also 
connected to the internet. In this way, both the buyer and the seller can communicate with 
the ICN system. The client system is described in greater detail below. In addition to the 
internet, other possible communication media include without limitation: cellular phone 
networks, pager networks and telephone networks. 

[0046] In addition to the ICN system 100 being connected to the buyer 110 and 
the supplier 120 via the communications medium 125, the ICN system 100 is also in 
communication with the respective banks of both the buyer and the supplier. The buyer bank 
130 and the supplier bank 140 are illustrated as being separately connected to the ICN system 
100, however it will be understood that this connection may also be via the internet. 
Although multiple connections are illustrated in Figure 1, it will be understood that a single 
communications network such as the internet may provide communications between all of 
the illustrated elements of Figure 1 . A schematic representation illustrating the use of a 
central communications medium such as the internet is shown in Figure 1 A. 
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[0047] Additionally, the ICN system 100 may also be in communication with 
other entities that facilitate the transaction between the buyer 110 and the supplier 120. One 
such example, as illustrated in Figure 1, is that one or more shippers 150 may be in 
communication with the ICN system 100. This allows the ICN system to mediate and audit 
the communications between the parties to the transaction and the facilitating entities. 

[0048] As will be described in greater detail below, the ICN system 100 is used in 
combination with the ICN client at the buyer 110 and supplier 120 in order to provide an 
architecture that allows for the real-time processing of electronic financial transactions 
between the buyer and supplier, including the real-time transfer of funds between the buyer 
bank 130 and supplier bank 140. 

ICN System 

[0049] Various functional components of the ICN system 100 will now be 
described with reference to Figure 2. These components are illustrated as separate functional 
blocks within the ICN system 100. However, it will be understood by those of skill in the art 
that these individual functions may be implemented in a variety of ways within the ICN 
system 100. For instance, these functions may be separate hardware devices, connected to 
one another by appropriate networking means, or may be software processes in 
communication with one another running on one or more pieces of general computing 
hardware. In general, any of the functions or modules identified within this disclosure may 
refer to any combination of software, firmware, or hardware used to perform the specified 
function or functions. 

[0050] The modules described herein are preferably implemented as software 
modules, but may be represented partially or entirely in hardware or firmware. It is 
contemplated that the functions performed by these modules may also be embodied within 
either a greater or lesser number of modules than is described in the accompanying text. For 
instance, a single function may be carried out through the operation of multiple modules, or 
more than one function may be performed by the same module. The described modules may 
be implemented as hardware, software, firmware or any combination thereof. Additionally, 



the described modules may reside at different locations connected through a wired or wireless 
network, or even distributed across the Internet. 

[0051] As shown in Figure 2, the ICN system 100 is connected to the 
communications medium 125. In particular, the communications medium 125 is in contact 
with a messaging server 210 within the ICN system 100 that receives and sends messages via 
the communications medium 125 to the other systems, e.g., the ICN clients at the buyer and 
supplier and the banks. The messaging server 210 routes messages received by the from the 
communications medium 125 to the other portions of the ICN system 100. A workflow 
engine 220 contains the logic which defines the appropriate response to various incoming 
messages and executes the decision-making process related to properly responding to 
incoming messages and taking the appropriate actions. The validation server 230 is used in 
authenticating individuals that are sending information to the ICN system 100. The ICN data 
dictionary 240 contains the definitions used in the various messages being exchanged 
between the buyer 110, supplier 120, and their banks 130, 140, as. well as other associated 
protocol definitions. Finally, the audit database 250 is a storage unit that receives and stores 
information associated with the various messages and transactions passed through the ICN 
system 100. 

[0052] As noted above, the messaging server 210 receives and routes messages 
from the communications medium 125 to the workflow engine 220. As noted in Figure 1, all 
transactions are mediated via a transfer network system 100 connected to both the buyer and 
the supplier, as well . as both of their banks. This allows for the automated and rapid transfer 
of data through the system to the various parties to the transaction. In addition, the ICN 
system 100 may be configured to automatically translate the required approvals and requests 
between various internal formats used by buyer 110, supplier 120 and their banks 130, 140 
into a standardized format in use by banks for other transactions outside of the ICN system. 
Examples of these formats and protocols include Universal Value Exchange (UVX) and 
Banking Internet Payment System (BIPS). 

[0053] Because the entire transaction is carried out across the communications 
medium 125 and the ICN system 100, accurate status information may be made available to 
all parties at all stages of the transaction. This transparency of status as the transaction 
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progresses through the authorizations from one party to the other, results in the full duplex 
nature of the transaction. As each phase of any process carried out through the ICN system 
100 takes place (several exemplary processes are described below), records are made in the 
audit database 250 and with the client involved in that message. Both parties retain visibility 
of the transaction at all times in real time if they so wish. In addition, because these 
transactions only need to wait for the approval by appropriate individuals at the client site 
with the appropriate authority, the transaction may proceed as fast as the available 
communications and authentication systems are able to handle the necessary processing. 
This results in the real time operation of the system. 

[0054] Note that although the term "real time" is used throughout this disclosure, 
there will necessarily be delays inherent in the operation of any transaction or transfer of data. 
This does not mean that the transaction is not occurring in real time. Within the context of 
this disclosure, "real time" may be broadly construed to refer to any transaction or event that 
is not placed into a holding queue for periodic processing which is often referred to as "batch 
processing". 

[0055] Real time events are generally those which are to be handled as rapidly as 
possible, even when such handling may incur delays associated with the transmission or 
authentication of particular data. As long as the requests are not collected and queued for 
periodic processing (i.e., 'batch' processing), that transaction may be considered to be real 
time. 

[0056] It should again be noted that unlike many other electronic systems 
designed to facilitate bank to bank transfers of funds, the current transfer network system is 
not designed to act as an account holder of either the banks or the parties to the transaction. 
No funds are committed on behalf of the ICN system 100 to settling and finalizing the 
financial transactions between the parties and banks. 

ICN Client 

[0057] In order to properly carry out transactions with the ICN system 100, 
appropriate ICN clients must be available to the buyer 110 and supplier 120. These ICN 



-8- 



clients will provide the appropriate hardware and software for a commercial user to transact 
through the ICN system 100. An exemplary ICN client system 300 is illustrated in Figure 3. 

[0058] The illustrated ICN client of Figure 3 is representative of the system that 
would reside at a buyer 1 10 or supplier 120. A similar client system would also be used for a 
shipper or bank, such as the buyer bank 130 or supplier bank 140. Although there are several 
components illustrated, as with the ICN system 100 described above, it should be understood 
that these functional modules may be separate physical pieces of hardware, or may be 
implemented as software modules running on one or more systems. 

[0059] A client site server 310 is illustrated as part of the exemplary ICN client 
300. The client site server 310 send, receives and processes the messages to and from the 
ICN system 100. The client site server 310 may include a messaging client responsible for 
receiving message from the communications network. The messaging client of the ICN 
client communicates with the messaging server 210 of the ICN system 100 via the 
communication medium 125. The appropriate processing logic required to evaluate and route 
information received from the ICN system 100 is also contained within the client site server. 

[0060] The ICN client 300 may also include one or more workstations. The 
illustrated exemplary ICN client 300 includes an entry workstation 320 and a management 
workstation 330. The workstations 320, 330 form the user interface through which people 
who are part of an electronic transaction take part. The workstations are used to initiate 
transactions, request proposals, respond to requests, approve or reject terms of a potential 
transaction, authorize payment, acknowledge receipt, and communicate with the other users 
in a transaction. 

[0061] A validation server 340 is also part of the ICN client 300. This server is 
used to provide functions related to the authentication and identification of users initiating 
and responding to messages for the ICN system 100. This is a complementary purpose to the 
validation server 230 of the ICN system 100 itself. 

[0062] An enterprise database 350 may also form part of the ICN client 300. The 
enterprise database 350 is a system that maintains data, processes, or other information useful 
to the operation of the business of the party operating the particular ICN client 300. For 
instance, an enterprise database for a bank will contain information about the bank's 
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accounts, the holders of those accounts, the personnel working at the bank and their 
respective jobs, etc. Similarly, enterprise databases for buyers 110 and suppliers 120 may 
contain information such as the general ledger information for the business, purchasing 
information and purchase order generation systems, inventory control, pricing guides, or any 
other information that is useful in the practice of the particular business at hand. 

[0063] As noted above, each client uses a variety of protocols and formats to 
provide the appropriate data interchange between the various parties, and between the various 
components within each system. The modules responsible for translating between the 
various protocols and formats are referred to as adaptors. Generally speaking, each system 
has one or more adaptors as needed in order to translate between the protocols in use in that 
system. The adaptors provide a means for the client site system 300 or ICN system 100 to be 
able to communicate with existing information systems, such as the enterprise database 350, 
without the need for a specialized equipment capable of working directly with the protocols 
and formats of the ICN system. Several examples are provided below. 

[0064] For instance, an adaptor located in the ICN client 300 of the buyer 110 can 
be used to handle data mapping and transformations between the standard data format in use 
at the buyer (for instance, the format used by the enterprise database 350 of the buyer 110) 
and the data format in use by the ICN client 300 for communicating with the ICN system 
100. An adaptor in the ICN client 300 of the supplier 120 provides a similar function in 
translating messages between the ICN system 100 and the internal systems of the supplier 
120. 

[0065] In a similar manner, adaptors in use at the banks 130, 140 of the buyer 110 
and supplier 120 handle data mapping and transformations between the format of the ICN 
system 100 and the format for the payment system used by the bank to transact internally and 
with other financial institutions. 1 In particular, the systems in use at the banks need to be able 
to translate messages received from the ICN system 100 into the appropriate messages to 
command the various financial transactions. These include 'make payment' and 'stop 
payment' instructions, as well as appropriate instructions to the various accounting systems in 
use at the bank, and queries related to transaction status. 
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[0066] In order to process the requests in an automated fashion, each bank will 
have to have its own server which handles messages transmitted in the protocol of the 
transfer network system 100. This server may comprise the client site server 310 for the ICN 
client 300 corresponding to the bank 130, 140. The protocol in use may be UVX, BIPS, or 
any other appropriate protocol As discussed above, the server may be a piece of software 
running on an existing computing device run by the bank, or in an alternate technique, the 
server may be an independent computing device running the appropriate software. Generally 
speaking, the various adaptors can be implemented as modules that run on the server and 
receive and parse messages into the formats used by the various internal systems of the bank. 

Transactions 

[0067] Having described the components of the architecture making use of the 
transfer network system or ICN system 100, the various transactions that can be carried out 
within this architecture will now be discussed. As mentioned above, the center of the present 
system is a transfer network system 100 that allows for electronic payment messages to be 
passed directly from a buyer's bank 130 to a supplier's bank 140 by the request of an account 
holder at the appropriate bank (i.e., the buyer 1 10 or the supplier 120). 

[0068] In a business to business transaction the general pattern for a payment 

involves a payor (in this case the buyer 110), having an account at his bank, requesting the 
transfer of some amount of money to the account of a payee having an account at a second 
bank. The transaction pattern for a payment varies depending on who presents the payment 
instrument to the bank. It may be the payee (e.g. in the case of a check or card at point of sale 
transaction) or the payor (e.g. in a giro transaction). 

[0069] Generally speaking, in giro transactions, a payment instrument is presented 
at the financial institution of the payor in order to send funds from an account of the payor to 
the account of someone else. One example of such a giro-style transaction is a wire transfer 
that is pushed from the payor's account. (It is also possible to have a wire transfer which is a 
draw from an account; however, such draw-style transactions operate in most ways similar to 
a check-based transaction.) 



[0070] Aside from the difference based upon the presenter of the payment 
instrument, the general pattern of a payment transaction is common to all money transfers, 
whether electronic, paper-based, or handled in person. 

[0071] In traditional payment systems, any payment is subject to a period of time 
during which the payment is not "final", i.e., the credit to the payee's account is subject to 
confirmation (after verification) by the payor's bank and to the clearing/settlement process 
between the banks themselves. In electronic payment systems, it is generally the case that the 
instructions related to the transfer of funds can be sent from one bank to another with great 
speed, and can often be processed in a somewhat automated manner. However, unless the 
transfer is being made within a single bank, or between banks that have accounts with each 
other, it takes time. 

[0072] The final settlement of the payment between the banks will take place via 
an interbank clearing/settlement system when each bank's account at their Central Bank is 
updated. For "normal" transactions {i.e., those that are not for very large amounts, by 
interbank standards) these systems normally work in "batch" mode. In batch mode 
processing, it is typical for transactions to be held in queue until it is time to process the 
accumulated transactions, either due to the size of the queue, or the time since the last batch 
processing. Typically, at the end of each business day or on some other regular interval, a 
bank will process all of its non-final transactions through its settlement system. As a result, 
there is still a delay between the time when all of the messages associated with the financial 
transaction have occurred (from the customer's point of view), but during which the transfer 
is not finally settled between the banks. 

[0073] Furthermore in an international environment, the inter-bank settlement 
may be complicated by differences in local banking standards unless both banks participate in 
the same international clearing system. Generally, this results in adding at least one more 
level of transaction in order for banks to settle the transaction between them. Although this 
interbank settlement transaction is always executed, there is none-the-less a delay associated 
with the time during which the transaction is not yet final. 

[0074] In a check or card system if the payor's account is not sufficiently credited, 
it will go at least twice through the whole chain, once in each direction. During the time it 
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takes to go through the chain of systems, the transfer is in an indeterminate state, awaiting 
finality. 

[0075] In the present system and from an information point of view the transfer 
network bypasses the institutional interbank systems. Each bank uses the network to verify 
and authenticate the individual sides of the bank to bank transaction electronically in a pre- . 
arranged format. The transfer network system provides assurances of the authenticity of the 
authorization to make the transfer between the banks. 

[0076] In the systems making use of the ICN system 100 to mediate financial and 
other business transactions, the ICN system 100 handles messages between the various 
entities described above. For instance, the ICN system 100 may handle messages travelling 
between a bank and its customer (e.g., between the buyer bank 130 and the buyer 110). The 
ICN system may also handle a message passing between two banks, such as the buyer bank 
130 and the supplier bank 140. The ICN system may also be used to handle messages 
travelling between the two business parties to the transaction, e.g., the buyer 110 and the 
supplier 120. Additionally, the ICN system 100 may handle traffic between one or more of 
the parties and a third party that is part of facilitating the transaction, e.g., the shipper 150 
identified in Figure 1. 

[0077] The ICN system 100 does not provide any financial accounts to any of the 
other parties, and does not handle any of the funds. However, a trusted settlement is still 
possible because of the legal reliability produced through the operation of the ICN system 
100. The ICN system need not be part of a financial institution handling funds or affiliated 
with any financial clearinghouse or traditional settlement agency. The transfer network 
merely brokers the data exchange that supports the level of trust required for two banks, 
neither of which has an account with the other, to provide finality of a transaction in real 
time. In effect, the ICN system 100 acts as a secure and trusted conduit for the instructions 
and metadata associated with a transaction. The only requirement is that the parties 110, 120 
and the banks 130, 140 are all equipped with appropriate client systems 300, 400 capable of 
properly interacting with the ICN system 100, as described above. 

Functional Architecture 
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[0078] Having described the structural architecture of the systems and 
components for providing secure, real time financial transactions with finality, the various 
functional aspects of the architecture will now be described. In the description that follows, 
the term "function" broadly to include any process or result that can be achieved through the 
use of the described systems and methods. 

[0079] In general, the functions provided within a particular embodiment of a 
system for providing real-time financial transactions with finality will be described. 
Although these functions may vary in implementation for different embodiments, they 
generally fall into three categories: service functions, security functions and support 
functions. 

Service Functions and Components 

[0080] Service functions are those functions that provide functionality directly to 
the users of the system. These users include the individuals using the ICN clients 300 as well 
as those users operating the ICN system 100 itself. In the described embodiment, these 
functions can include: payment message generation and distribution; non-payment message 
generation and distribution; payment message handling by participants; interfaces to existing 
systems of participants; identity management; full-duplex communication between 

r 

participants; and collection of transaction fees. 

[0081] The payment message generation and distribution function is directed to 
providing the ability for a user of an ICN client 300 to generate a document to authorize a 
payment to be made through the ICN system 100. Executing this process requires that the 
user have the appropriate level of payment authority and also that the user digitally sign a 
binding statement that commits the user and his organization to the particular payment. 

[0082] Regardless of whether the commercial transaction associated with the 
particular payment occurs electronically across the ICN system 100, or is carried out across a 
different network, or even by hand, a transaction that requires a payment to be made will 
always involve an invoice to be credited to the accounts payable of the supplier 120 (the 
payee) and debited to the accounts receivable of the buyer 110 (the payor). An example of 
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the script associated with the payment generation and distribution process is shown in Figure 
5. 

[0083] Once the buyer 110 has an appropriately entered invoice in their accounts 
payable system, someone from the buyer 110 will log in with the appropriate authority and 
make the request that the payment on the invoice be made (see Step 1), using all of the 
appropriate validation and authentication required to establish that the individual assenting to 
the payment has the appropriate authority. In addition, the message which will be signed will 
include all of the appropriate data representing the party to whom the funds will be paid, and 
with which invoice these funds are associated. 

[0084] In particular, this assent is preferably indicated via a digitally signed 
certificate which authenticates the authorizing party to be an individual within the buyer 110 
organization with the appropriate "invoice authority", and also includes all of the appropriate 
data representing the party to whom the funds will be paid, and with which invoice these 
funds are associated. This data will be transferred in a standard format which can be 
automatically verified by the transfer network system against an appropriate digital certificate 
authority; storing a copy of the signed digital document in a database associated with the 
transfer network system. Note that "invoice authority" need only be the authority to accept 
an invoice on behalf of the buyer 110. An individual having invoice authority does not 
necessarily have the authority to transfer money out of the financial accounts of the buyer 110 
(i.e., authority to pay the invoice). This latter authority is referred to as "payment authority". 

[0085] Once assented to, a digitally signed message will be created and sent, 
using the protocols and procedures described above, to the ICN system 100. This payment 
request will be authenticated to confirm the authority of the person signing the request, and a 
copy of the signed digital document will be stored in the audit database 250 of the ICN 
system 100. 

[0086] Once this assent is authenticated and stored at the ICN system 100, an 
appropriate message to the buyer bank 130 is sent. This message instructs the transfer of 
funds from the account of the buyer 110 at the buyer bank 130 to the account of the supplier 
120 at the supplier bank 140. The ICN client 300 at the buyer bank 130 validates the 
incoming message, and once it has authenticated that the appropriate authority for the transfer 
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is manifested and legally assented to in the message, a copy of the signed payment 
authorization is stored by the buyer bank 130. A confirmation of the approval (such as a 
copy of the authenticated assent) is sent to the supplier 120. 

[0087] An payment instruction verifying the transfer of funds out of the account 
of the buyer 1 10 at the buyer bank 130 is created, and this instruction is sent to the transfer 
network system 100 for routing to the supplier bank 140. The message with the payment 
instruction is sent from the transfer network system 100 to the supplier bank 140, and an 
appropriate electronic payment receipt verifying the transfer of funds out of the buyer's 
account and into the seller's account is created. This receipt is sent back to the transfer 
network system 100 for storage in the audit database 250. One example of a process 
illustrating the above described transaction is shown in Figure 18. 

[0088] Because of the authentication of the identity of the individual assenting to 
the transfer between the banks, and the careful record keeping and tracking of the messages 
as they proceed from the ICN client 300 to the ICN system 100 and on to the appropriate 
banks 130, 140, the systems performing the transaction described above are able to provide 
certain real-time finality for the transaction. Such real-time finality is not possible without 
the ICN system 100 and its associated procedures and protocols. 

[0089] By providing a trusted medium for the exchange of legally binding and 
digitally signed assent to the transfer of funds, the banks are able to process the transaction as 
if they had received an appropriately signed physical payment instrument. Furthermore, 
because the identities, authorities, and messages associated with the transfer can be validated 
in an automated fashion using the validation servers 230, 340 of the ICN system 100 and the 
ICN clients 300, the finality is achieved even more quickly than with physical payment 
systems. 

[0090] By having appropriately stored and authenticated copies of the signed 
messages and receipts associated with the transaction, and by having the messages provide 
the appropriate level of legal certainty required by the Electronic Funds Transfer Act, the 
transactions carried out electronically between the two banks can be finalized immediately, 
without the need to wait for any portion of the transaction to clear through a central clearing 
house settlement process. The transaction is settled in real-time. 
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[0091] This is possible because the supplier bank 140 that is receiving the inflow 
of funds is able to trust in the same authority that was manifested in the digitally signed 
payment instruction forwarded to the buyer bank 130. Once acknowledged by the supplier 
bank 140, the transfer is accomplished, and the transaction is now complete with no obstacle 
to the final settlement arising from the business parties, since the identity and assent and 
authorization of all parties has been properly validated by each other party to the transaction. 
This mutual cross-validation provides trust sufficient to allow the effective quantification of 
the risks associated with a potentially bad transaction. Because of the quantifiability of the 
reliability of transactions carried out using this system, such transactions may be able to be 
insured, similarly to the transactions carried out through a settlement clearinghouse. This 
will be discussed in greater detail below. 

[0092] Another aspect that supports the trust of the electronic transaction is 
related to the fact that all ICN clients 300 can only be used under a proper service level 
agreement (SLA) between the buyer, seller, or bank using the ICN client 300 and the operator 
of the ICN system 100 itself. This SLA is used to provide a legal framework mandating that 
the equipment and software in use as the ICN client 300 conforms to appropriate security 
standards. In exchange for these duties of maintenance and particular terms of operation, a 
level of legal confidence can be associated with the transactions performed and records stored 
on these systems. 

[0093] This also allows each party in the transaction to get insured for the liability 
that they are carrying. Unlike a traditional electronic system where insurance underwriters 
cannot depend upon the reliability of electronic records, and transactions reaching a 
predictable level, the systems presented herein allow a quantifiable and reliable level of trust 
in the information presented. This is made possible through the use of secure electronic 
techniques (such as encryption and user authentication), appropriate legal frameworks and 
duties associated with using the system (service level agreements) and the use of legally 
binding language being attached to all messages that commit a party to a transaction (the use 
of Regulation E compliant language in the digitally signed and authenticated messages). 

[0094] In addition to the general transaction script described above and shown in 
Figure 18, another function that has to be provided is for the case where messages are passed 
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between the buyer 110 and the supplier 120, but there is no financial transaction that takes 
place. In such circumstances, the ICN system 100 is still used to mediate the interaction, but 
no communication is necessary between the ICN system 100 and the banks 130, 140 of the 
buyer 110 and seller 120. 

[0095] One example of such a transaction is shown in Figure 11. This particular 
example of a non-financial transaction message is related to the placing of an order by the 
buyer 110 with the supplier 120. As can be seen in the Figure, the buyer initiates the 
transaction in step 1, and prepares an order message which is forwarded to the ICN system 
100 for authentication and forwarding to the supplier 120. The Figure illustrates how the 
appropriate back and forth interactions between the buyer 110 and the seller 120 are mediated 
the ICN system 100 in the same way in which the transfer network system was used to - 
mediate a payment instruction from the buyer bank 130 to the seller bank 140. Once the sale 
terms are agreed to by both parties authorizing equivalent sales terms, the appropriate 
transaction can be initiated, for instance by ordering the delivery of goods to the buyer 110. 
Both companies can update the information in their ICN clients 300, and can also pass the 
appropriate information to the enterprise database 350 to update the general ledger, inventory, 
accounts receivable or other internal data related to the transaction. 

[0096] Regardless of whether the above transaction occurs electronically across 
the same transfer network 100 mediating any financial communications, or is carried out 
across a different network, or even by hand, the business transaction will result in an invoice 
which is to be credited to the accounts payable of the buyer 110 and debited to the accounts 
receivable of the supplier 120. 

[0097] A third type of service function that is provided is payment message 
handling by the banks that are ICN clients 300. This function handles the processing of 
instructions that are normally provided in standard interbank formats and protocols, such as 
InterBIPS. Standard instructions are received by a bank, and these instructions are routed 
through the appropriate adaptor to be processed by the bank. 

[0098] When, for example, the buyer bank 130 receives this data, it is in a format 
which the bank 130 is able to process automatically in order to determine the appropriate 
transfer to execute with respect to the supplier bank 140. Normally, at this stage, the process 
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would be delayed as the buyer bank 130 was forced to verify the authority of the individuals 
who approved (i.e., signed) the electronic payment instructions, and the transaction would 
remain unsettled and non-final during this period. However, because the buyer bank 130 is 
able to validate that the transaction was signed by an individual of appropriate authority at the 
buyer 110 (via the digitally signed documents that are forwarded from the transfer network 
system 100), the buyer bank 130 can process the transaction request in real-time (i.e., as it is 
received) and directly approve the transfer of funds, informing the transfer network system 
100 of its approval of the transaction. 

[0099] Another service function that is provided is that of identity management. 
Identity management refers to the process of managing and maintaining the database of 
profiles of individuals and how they are authorized to use the functions available through the 
ICN system 100 and ICN clients 300. This function is related to the authentication function, 
as well as the directory services components discussed below with respect to the security 
functions. Through the appropriate use of identity management processes, alerts can be 
triggered, abuses can be detected and responded to, and auditing of transactions can take 
place. 

[0100] As discussed above with regard to non- financial message exchanges, the 
service functions also include the ability to provide for full-duplex communication between 
the various ICN clients 300 that are connected to the ICN system 100 by the communication 
network. This follows the same script and pattern as described above. This allows for the 
real-time exchange of text message in a bi-directional exchange. This capability (as 
discussed above) is only available when both parties have access to and active connections 
with the ICN system 100. 

[0101] One additional service function provided by the systems described herein 
is that of transaction fee collection. This is a function that allows tracking of the amount of 
traffic and the value of the transactions associated with particular ICN clients 300. This 
information can be stored and aggregated in order to provide an appropriate basis for usage- 
based billing of the parties making use of their ICN clients. Additionally, this information 
can automatically be used to generate invoices which can be sent in a properly pre-formatted 
payment message by the ICN system 100. 
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Security Functions and Components 

[0102] Security functions are the functions provided and enabled by the 
architecture that address the issues related to the trust that can be placed in the information 
flowing through the ICN system 100. In particular, security functions are used to prevent 
transactions that are not properly authorized or authenticated from taking place, and alerting 
the appropriate ICN clients 300 and individuals using the system so that the failure of the 
transaction may be addressed. Such failed transactions may be due to a variety of improper 
operation circumstances other than improper authentication. For instance, a failure to deliver 
a message across the communications medium 125 may result in a failure for a script for a 
particular process to be followed successfully. Similarly, the crash of one of the systems, for 
instance, the validation server 340 at an ICN client 300, could also terminate the progress of a 
pending process, and require an alert to be generated. 

[0103] The various modules and components of the ICN system 100 and ICN 
clients 300 interact with the security functions that may be provided by the clients themselves 
and the underlying communications medium 125. Security related data may be obtained via 
the operating system and appended to messages transferred between the ICN system 100 and 
the ICN clients. This allows the various modules to identify what data and processes are 
associated with specific users. Through the use of the identity management functions 
described above, the transaction security data can be associated with the appropriate 
messages and authorizations. 

[0104] One example of a type of security data that can be derived is the 
Organizational ED (OID), which is a part of the Black Forest Group Quality Attribute, defined 
by the X.509v3 standard. 

[0105] Audit functions are a type of security function that is provided. As 
transactions occur and the messages related to those transactions are passed through the ICN 
system 100, the events and messages are audited by the ICN system 100. During the audit 
process, two types of audit are performed. 

[0106] The first is performed at a data field level, where the content if the field is 
examined to detect alterations that may have been made by another user. This is different 
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from the standards based integrity checks (either hash or Hamming) that are performed to 
ensure data fields have not suffered data degradation due to any manner of electronic 
malfunction or disturbance, like exposure to electro-motive force (in transmission) or electo- 
magnetic force (hard disk storage). This comparison is used to identify the party who is 
responsible for the changes to the data in the message. If changes in the data are found where 
they should not be found, an alert or responsive event to the alteration in the data can be 
triggered. 

[0107] The second type of audit is the creation of audit data records in the audit 
database 250 of the ICN system 100. The audit records are build from the continuous flow of 
discrete data transactions and captured in a transaction tracking system which records each 
discrete transaction to prevent data loss in event of a computer "down", transmission failure, 
or general power loss. The data file of the audit record is formed and provided with a 
subsequent integrity check from the operating system. The actual media used for the audit 
database archiving must provide suitable levels of data recovery capability in event of 
electronic or physical damage. 

[0108] This audit trail that is provided by the information placed into the audit 
database 250 provides a level of trust to users of the system. This is because any transaction 
which is mediated through the ICN system 100 will have the appropriate authenticated 
messages identified in the audit database, allowing for a quantifiable ability to review and 
evaluate transactions after they have occurred. By providing such a capability for reliable 
after the fact analysis and reproduction of transactions as they originally occurred, the system 
becomes reliable in a manner very similar to systems which make use of physical markers 
(such as signed checks) to provide an auditable record of past transactions. Such quantifiable 
trust in the system can allow insurers to have the ability to underwrite policies that depend 
upon known levels of reliability in the transactions being carried out, so as to limit the total 
liability exposure of the parties to transactions mediated through the ICN system 100. 

[0109] In addition to audit functions and functions provided through the 
capabilities of the ICN system 100 or the ICN clients 300, other security functions are also 
available through the operating system or through third-party software. These can include, 
for example, digital certificate analysis software for identification purposes. For example, 
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when identity authentication is performed during a log in process, the operating system 
compares a data "secret" presented by the end-user with a secret available to the operating 
system. The operating system can audit these events as well. It will be understood that a 
variety of different digital signature authorities could be used without altering the 
fundamental nature of the system described. 

[0110] So when specific security functions of the network or operating system are 
executed, the network or operating systems security and audit features can record the activity 
along with the logged in identity for the activity. Selected data fields from the system's audit 
record can then be sent to the ICN system or client and analyzed after the fact. More detail 
regarding logging in to the ICN system can be found below. 

[0111] These audit features form s the basis for a continuous audit, and allow 
transaction audit records to be compared with system audit records in order to perform 
specific data analyses. A common comparison that may be performed via the network and 
operating system's security functions is a comparison related to the use of a digital certificate. 

[0112] Additional security functions of the network and operating system can 
provide the basis for establishing and corroborating the security functions provided by the 
ICN system 100 and ICN clients 300. 

[0113] One such feature is authentication. The process of corroborating an 
identity and the resultant assignation of identity within the operating systems is used 
throughout the processing performed by the ICN system and ICN clients. Such functions 
require both network log on and an appropriate log in of a user of appropriate authorization. 
(Log on and log in are discussed in greater detail below.) Such end to end authentication 
increases the reliability and trust that can be generated by the systems described herein. 

[0114] Another standard that plays a role in the security functions available when 
using the ICN system 100 is the X.509 V3 standard. Different from Identity authentication 
techniques and systems (like the log in process described below) are identity management 
regimes. One example is the Public Key Infrastructure (PKI) component of Registry 
Authority (RA). The RA uses cryptography to bind the names of participants with 
electronically discernable markings for identity. 
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[0115] To obtain the highest level of clarity and verifiability for use with I-C 
transactions, electronic identities are bound to the individuals using the ICN clients 300 using 
the X.509 V3 standard for digital certificates and in accordance with the Black Forest Group 
Quality Attributes. The combination of X.509 digital certificates with the V3 (version 3) 
Black Forest Group Quality Attribute extensions allows any participant company to advertise 
their employees' electronic credentials via X.500 directory services. This also allows other 
participants to access these credentials via directory protocols, such as LDAP. The 
credentials provided by the supplier 120 can be used by the buyer 110 and vice versa. 
Similarly the credentials provided by the ICN system can be used by all participants and ICN 
clients, and the use of these reference numbers with the quality attribute. 

[0116] Throughout the authentication and credential related processes described, 
analysis of the credentials is performed by appropriate processing on the validation servers 
230, 340 of the ICN system 100 and the ICN clients 300. 

[0117] Various uses can be made of the authentication and comparison features 
available through the validation servers. Digital certificates can be decomposed into data 
fields for comparison, e.g., the Company Name and Individual Name in the X.509 certificate 
can be compared with those in the X.509 V3 extension to ensure they are the same. Elements 
of the X.509 V3 certificate can be resolved by the validation server to determine what an 
individual may have been authorized to do in the course of business. Based upon the 
electronic policies of the certificate consuming company, suitably defined access controls can 
be defined for use in allowing access to data or services. 

[0118] As mentioned above, alerts may be provided in order to provide notice to a 
user or administrator or other individual associated with the ICN system or client when a 
process is outside the expected behavior. For instance, lack of digital certificate integrity can 
be used to signal an immediate alert from the validation server. Other examples include 
noting a potential abuse of the system when any conflict in information between the digital 
certificate of a client and the ODD of the Quality Attribute. 

[0119] Abuse management is a function that relies on a pre-established scheme of 
known and unknown exposures. When using the architecture and systems described herein, 
various types of abuse management functions may be made available. They include without 
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limitation: protection and deterrent mechanisms, and the ability to trigger real-time or 
delayed countermeasures. Such features can make use of login metrics, initiation algorithms, 
data capture and communication checks, including checks based on the quality attributes of 
certificates used throughout the sessions. Such information can be used to generate 
appropriate error messages for transmission and display to an appropriate user. These abuse 
warning may also be recorded in the audit database 250 of the ICN system for later review 
and analysis. 

[0120] The ICN system 100 provides content abuse detection and alerting. In 
addition to the abuse detection provided by the ICN client's validation server 340, the ICN 
system 100 services include abuse detection of content for content management. The ICN 
system records the streamed audit of all transactions and files the audit records in the audit 
database 250 for subsequent review. 

[0121] Communications between the entry workstation 320, the management 
workstation 330 and the various other devices may be made using a Secure Socket Layer 
(SSL) protocol to protect data transmissions. SSL protocol yields session level encryption 
and provides a distinct identity for the workstation communications protocols. This further 
allows a greater degree of data protection to the ICN system 100 and a higher degree of trust 
in the data stored therein. 

[0122] As discussed above, directory services, such as X.500 standards-based 
directories, are used by the ICN system and ICN clients and their various components for 
proper addressing. Any of these components or the modules running on them can look up the 
correct address for any other individual registered with the ICN system. The information 
available includes address specifics, company names (e.g., X.500 Distinguished Name), as 
well as specific information in the Black Forest Group defined Quality Attribute. 

Support Functions and Components 

[0123] The support functions deal with operation and maintenance of the system 
under normal conditions and back-up or recovery. These functions may include without 
limitation: a gateway to clients that only allows properly authenticated communications, i.e., 
communications from users validated through a validation server; an internal secure hub for 
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the exchange of information between all software modules of the ICN system and the ICN 
clients, based on a workflow engine and audit records; a message repository; a data dictionary 
and configuration metadata; and maintenance functions for recovery and backup. 

[0124] The workflow engine 220 defines and executes different workflows. The 
workflow engine 220 creates standard and ICN data objects based on the ICN data dictionary 
240 definitions. The workflow engine 220 handles mapping and conversion between business 
data objects in different formats. The workflow engine executes data validation and business 
validation rules. 

[0125] The ICN data dictionary 240 defines both the standard messaging set and 
the ICN messaging set. The ICN data dictionary defines mapping and conversion information 
between internal and external data formats. Internal data formats are standard and ICN 
format. The different interfaces with the ICN clients for the buyer 110, supplier 120 and 
banks 130, 140 each define external data formats. 

[0126] Service, security and support functions are implemented accordingly as 
software elements on either standard or secure (EAL level 2 or level 4) platforms. Because 
the transfer network system 100 does not actually perform the transfer of any of the funds 
between banks (this is handled directly between the banks using any ordinary settlement 
system), the digital documents can be used in the same way that paper copies of signed 
payment orders or checks would be used. This allows the transfer network system operator to 
only be liable for the authenticity of the documents they transfer, and not the funds at issue. 

[0127] It should be noted that the appropriate language necessary to bind the 
parties legally to the transaction may be inserted in the appropriate interfaces and digital 
documents which are signed and authenticated. In addition to providing the appropriate 
support for the authenticity of the documents, if it ever becomes necessary to prove the 
validity of the transfer instruments at a later time, the interface associated with presenting and 
digitally signing these documents may also be configured so as to comply with the 
appropriate regulations governing the transfer of funds. For instance, appropriate consent and 
warning language in order to comply with Regulation E or other regulations implementing 
the Electronic Funds Transfer Act, may be inserted into the documents that are digitally 
signed by the appropriate parties. 
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[0128] In addition to the embodiments described above, certain additional 
functions/components may be added to the system. For instance, a data clearing house entity 
may be configured to hold copies of all transaction instruments recorded by the transfer 
network system, and then periodically post these results to the appropriate entities for final 
settlement and storage. Note that this data clearing house need not clear actual financial 
transactions, but may act as a daily data repository which is periodically (e.g., daily) posted. 

[0129] The transfer network system can also be configured to work in conjunction 
with a foreign currency exchange operated by one of the member banks in order to expedite 
international electronic bank to bank transactions. The general operation of the system is 
substantially as described above. However, when a particular transaction requires funds to be 
converted from one currency to another, this can be performed by the currency exchange 
under the control of the appropriate transacting bank. 

[0130] Note: in the description and Figures associated with the various 
transactions and transaction scripts, certain conventions are used. In each Figure in which a 
process or script is displayed, the first row of the Figure represents the various parties to the 
particular process being discussed. These may include, for example, the buyer 110, or the 
ICN system 100, or even a particular portion of one of the participating systems, for example, 
the messaging server 210 or the management workstation 330 at a supplier 120. As the steps 
of the process are followed (the steps are numbered separately for each Figure in the far right 
column), the activity or state of each of the participating systems is noted underneath the 
heading for that particular system. In addition, it should be noted that the abbreviation WS 
represents "workstation". 

[0131] Figures 4-22 illustrate a variety of different transaction scripts that can 
occur during the interaction of the ICN system 100 with various ICN clients 300. These 
transactions include transactions that do not involve financial exchanges (see Figures 4-10); 
transactions that produce an order or invoice that is intended to be paid (see Figures 11-14); 
transactions that relate to adjacent processes such as shipping of goods in response to a 
properly approved order (see Figures 15-17); and transactions that result in the generation of 
payment instructions to transfer funds between financial institutions (see Figures 18-22). . 
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Generic Message Exchange Script 

[0132] A generic script that covers the basic process for the creation and 
transmission of a message between a client (either a transaction party or a bank) and the ICN 
system 100 will now be described. This script provides for a secure creation and delivery of 
a message to the ICN system, and will be used whenever a communication with the ICN 
system is initiated by any client system, whether the communication is related to a 

commercial portion of a transaction or a financial portion of a transaction. 

< 

[0133] The first step is for the client, who is the sender of the message, to 
generate at one of the workstations 320, 330 an order or request document. This document is 
prepared by a user, using the appropriate software on the workstation 320, 330 and is signed 
by accessing the validation server 340 and providing an appropriate authentication. In 
response to the authentication information, the validation server 340 will provide a digital 
signature that is attached to the message to be sent. 

[0134] The message, now digitally signed, is then sent to the ICN system 100 
electronically across the communication medium 125. This message will comprise data in a 
standard format which can be automatically verified by the ICN system 100 against an 
appropriate digital certificate authority, generally the validation server 230 of the ICN system 
100. A copy of this signed digital message is stored in the audit database 250. 

[0135] Once the message is authenticated properly by the validation server 230, 
an authorization request is sent back to the ICN client 300 from the ICN system 100. This 
request is routed to the management workstation 330 for approval by an appropriate 
individual having approval authority, as defined by the validation server 340 at the ICN client 
300. Upon receipt, this message is also authenticated against the validation server 340 to 
confirm that it was sent from the ICN system 100. 

[0136] When an appropriate user at the management workstation 330 goes to 
approve the request, he is presented with an appropriate interface screen giving the relevant 
terms of the request being approved, as well as information making clear that any digitally 
signed message made in response to this request is legally binding. In particular, the 
language of this message can be made to conform to whatever legal standard is required for 
creating a properly legally binding signature. Such language may, in particular embodiments, 
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be made to provide appropriate consent and warning language in order to comply with 
Regulation E or other regulations implementing the Electronic Funds Transfer Act. 

[0137] An example of type of term that is used to comply with Regulation E can 
be seen in the payment process shown in Figure 26. As can be seen in the column showing 
the tasks performed by the payor (generally the buyer 1 10), an agreement screen is presented 
that provides the appropriate Regulation E disclosures, along with the appropriate disclosures 
related to the ICN system 100, and the legal agreement that the payment to be made on this 
invoice is final and legally binding. A copy of this digitally signed document is stored by the 
ICN system 100. 

[0138] Another agreement providing the equivalent language needed to bind the 
payor's bank is also digitally signed, and forwarded to the payor bank for storage within the 
ICN client of the payor's bank. By having appropriately signed digital messages stored by 
both the bank and the payor, the finality of the transaction can be reliably assured, since each 
party has information that can be used to show that there was a legal transfer of funds 
intended and properly authorized by the payor from the payor's bank. 

[0139] This message, once signed, is then sent back to the ICN system 100. The 
ICN system 100 appropriately authenticates that the user approving the order/request has the 
appropriate authority via the validation server 230, and a copy of the signed authorization 
request is stored in the audit database 250. 

[0140] Notice of the approval of the order/request message is then sent to the 
intended recipient of the message. Such notice may be a copy of the authenticated assent to 
the message. An acknowledgement may also be sent to the sender. 

[0141] This process is described as relating to an initial message between a sender 
and a recipient. However, the same process is used with the sender and recipient reversed 
when a message is responded to. The responding party (the recipient of the above described 
process) will send a response message to the ICN system 100, where it will be validated and 
sent back for authorization. The responding party will have an appropriate individual 
authorize the communication, after validating that it came from the ICN system 100, and then 
will send the digitally signed message back to the ICN system 100 for validation and 
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forwarding to the sender of the original message. Copies will be stored in the audit database 
250 as described above. 

[0142] This process is generic to all communications through the ICN system 
100, and will be used whenever a communication with legally binding significance is made 
between the parties. In addition to the validation and digital signature processes which are 
described, it should also be understood that encryption can be used as appropriate to further 
secure the contents of the messages being exchanged if this is desired. The details of the 
particular encryption scheme may be varied as needed, and do not effect the overall operation 
of the systems described herein. 

Logging On and Logging In 

[0143] Within the Figures and description that follow, two different processes 
related to establishing connections between the various described systems are noted. The 
first is called "logging on" to the ICN system 100. Logging on is the process of establishing 
a network connection between a particular ICN client 300 and the ICN system 100. This 
process is essentially similar to establishing a virtual private network (VPN) connection 
between the two systems. Data sent across this VPN is actually carried across the 
communications medium 125; however, an additional VPN protocol is applied on top of the 
normal protocols in use for the communications medium in order to establish the private 
nature of this communication. This logging on process is performed prior to the exchange of 
any messages or data that are to be carried across the ICN system to any other system. 

[0144] In logging on, the ICN client 300 must properly authenticate itself to the 
ICN system 100. This does not require the acknowledgement of any particular user at the 
client 300 or any particular authority level, but merely an authentication that establishes that 
the ICN client 300 is a established client known to the ICN system 100 and trusted to transact 
across the ICN system. 

[0145] Once logged on, this VPN connection is used for any further 
communication between that client 300 and the ICN system 100 until the end of that 
particular communication stream. For instance, in order to send a request for quotation 
(RFQ) message to a supplier 120, the ICN client 300 of the buyer 1 10 must first log on to the 
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ICN system 100 and establish the appropriate connection. Similarly, prior to passing the 
message along to the supplier's ICN client 300, the ICN system 100 must establish the proper 
VPN connection by having the supplier's ICN client log on to the ICN system. 

[0146] All communications to be carried between any of the ICN client systems 
300 and the ICN system 100 will be carried across this VPN connection only once the client 
is properly logged on. For security purposes, encryption may be used at the VPN level in 
order to secure all of the traffic carried across the communications medium 125. Such 
encryption is a common feature of VPN systems. 

[0147] Separate from the "logging on" process described above, the process of 
"logging in" is used to refer to the authentication and validation of individual users with 
particular levels of authority to transact across the ICN system 100. Logging on is a process 
which is carried out automatically by the ICN client 300 and ICN system 100 as needed in 
order to maintain a private communications channel across the potentially insecure 
communications medium 125. By contrast, logging in is a process initiated by a user in order 
to establish their credentials to carry out a transaction on behalf of the entity they represent 
(e.g., the buyer 1 10 or the supplier 120). 

[0148] The process of logging in as a particular user is discussed in greater 
technical detail below. While logging in establishes that the particular ICN client 300 that is 
connecting to the ICN system 100 is properly authorized to exchange messages with the ICN 
system 100, logging on establishes the appropriate authority level associated with the 
particular individual that will be applying a digital signature to the messages that are being 
sent. This step of logging in is particularly important for those signed messages which are to 
be used as an indication of a legally binding transaction. For instance, in order to properly 
bind one of the parties, an appropriate message containing the warnings and consent and 
warning language in compliance with Regulation E may be digitally signed. However, such 
signature must be made by a party properly identified and validated to have the authority to 
properly bind the party. Logging in establishes the identity and authority of the digitally 
signing individual. 

Trust, Finality, Liability Allocation & Real Time 
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[0149] The use of the network transfer system may avoid any liability associated 
with repudiated transactions (as will be discussed below) and may also eliminate the 
necessity to verify the availability of funds to cover the transactions requested. 

[0150] Instead, the transfer network system is only liable for the accuracy of the 
data they provide, and the reliability of the authenticated documents that they store and 
deliver. By acting as a data delivery and authentication service, the transfer network system 
is able to forward the appropriate transfer requests and confirmations immediately, without 
having to perform any of its own checking as to the viability of the accounts held with the 
banks. 

[0151] The financial accounts are handled by the banks themselves, and only the 
results of the transactions into and out of those accounts are forwarded through the transfer 
network system. In this way, the transfer network system need not vouch for the validity of 
the transfer itself, but rather only for the validity of the request being made via the electronic 
instrument. 

[0152] By vouching for the validity and authenticity of the requests, the transfer 
network system provides a level of trust to the automated communications between the banks 
when requesting and confirming the payment and transfer of funds. 

[0153] This trust is normally generated by having banks either intermediate their 
transactions through a trusted third banking institution, such as a Federal Reserve Bank or 
some other clearing house, or by having one of the banks have an account with the other. 

[0154] The system described herein reinforce the trust mechanisms. The 
appropriate level of trust in the transaction instruments is backed by the authentication system 
and the ability of the bank to digitally verify the authenticity of the transfer documents in real 
time and in an automated manner by having these documents created and signed 
electronically. 

[0155] The transfer network system 100 provides merely a trusted 
communications system for the banks. The banks can transact with trust in the documents 
used to initiate and validate the transfer. This is possible because the authentication 
documents stored by the transfer network system are able to be used to support the legitimacy 
of any transfer if required after the fact. In addition, by vouching for the validity and 
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authenticity of the requests and responses, the transfer network system provides a level of 
trust to the automated communications between the banks when requesting and confirming 
the payment and transfer of funds. This allows a state of finality to be reached in real-time. 
Finality is the state where there are no remaining obstacle to final settlement of the fund 
transfer (e.g., there is a good faith belief by both sides that the transfer of funds is legitimate; 
there is no reason to suspect that the transaction will be repudiated by one or the other party; 
there is a legal basis for compelling the transfer of funds to occur in the even the transferor 
refuses). 

[0156] Furthermore the systems described herein reinforce the trust mechanisms. 
The appropriate level of trust in the transaction instruments is backed by the authentication 
system and the ability of the bank to digitally verify the authenticity of the transfer documents 
in real-time and in an automated manner by having these documents created and signed 
electronically. 

[0157] The use of the network transfer system may also avoid any liability 
associated with repudiated transactions as it significantly reduces the possibility of a 
repudiated transaction. For instance, a transaction will not proceed from one step to the next 
unless the former step has been validated and approved by the authorized person and/or its 
compliance to agreed procedures and values (limits) has been automatically checked. 

[0158] By setting up a system in which the electronic instruments of fund transfer 
can be relied upon to the same degree as the physical tokens associated with ordinary fund 
transfer, it becomes possible to allow the banks to maintain their ordinary responsibility for 
the transfer of funds, while allowing the operator of the ICN system 100 to only be liable for 
the integrity of the data received and sent, and the reliability of the authenticated documents 
stored and delivered. 

[0159] By acting as a data delivery and authentication service, the transfer 
network system is able to forward the appropriate transfer requests and confirmations 
immediately, without having to perform any of its own checking as to the viability of the 
accounts held with the banks. The financial accounts are handled by the banks themselves, 
and only the results of the transactions into and out of those accounts are forwarded through 
the transfer network system. 
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[0160] In this way, the transfer network system needs not vouch for the validity of 
the transfer itself, but rather only for the validity of the request/ confirmation being made via 
the electronic instrument. Such a system speeds interbank clearing. This is unlike 
transactions in which banks either intermediate their transactions through a trusted third 
financial institution, such as a Federal Reserve Bank or some bilateral or multilateral clearing 
house, or by having one of the banks have an account with the other. 

[0161] In classical systems the validation of the transfers calls for feedback, 
which leads to greater delay and overhead processing time. The described systems and 
techniques enable banks to settle transactions in one pass thus getting rid of "multipass" 
overheads and, again, reducing the time to reach the confirmation of final "money 
settlement". 

[0162] In this way, the banks can transact with trust in the documents used to 
initiate the transfer. The transfer network system provides merely a trusted communications 
system for the banks, rather than a trusted financial account. This allows for the transactions 
to settle with finality in real time, and provides for non-repudiation of the transfers, without 
the overhead of third party financial accounts or intermediary banks, as are used in many 
other systems. 

[0163] In addition, the authentication documents stored by the bank and by the 
transfer network system are able to be used to support the legitimacy of any transfer if 
required. 

[0164] In addition to the description provided above and in the associated Figures, 
additional details regarding the various components and techniques described herein may be 
found in the attached Appendix. 

[0165], The various server and client systems and the techniques for their use, as 
well as the variations in each that are described above thus provide a number of ways to 
provide secure, real-time finality to financial transactions between two parties. In addition, 
the techniques described may be broadly applied for use with a variety of non-financial 
transactions and adjacent processes as well. 
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[0166] Of course, it is to be understood that not necessarily all such objectives or 
advantages may be achieved in accordance with any particular embodiment using the devices 
or techniques described herein. Thus, for example, those skilled in the art will recognize that 
the devices may be developed in a manner that achieves or optimizes one advantage or group 
of advantages as taught herein without necessarily achieving other objectives or advantages 
as may be taught or suggested herein. 

[0167] Furthermore, the skilled artisan will recognize the intefchangeability of 
various features from different embodiments. For example, variations in the authentication 
protocols used by the ICN system and client may be combined with systems in which 
encryption is applied to more fully protect the messages in transit across the internet. These 
various aspects of the system design and its associated processes, as well as other known 
equivalents for any of the described features, can be mixed and matched by one of ordinary 
skill in this art to produce other architectures, devices and techniques in accordance with 
principles of the disclosure herein. 

[0168] Although these techniques and systems have been disclosed in the context 
of certain embodiments and examples, it will be understood by those skilled in the art that 
these techniques and systems may be extended beyond the specifically disclosed 
embodiments to other alternative embodiments and/or uses and obvious modifications and 
equivalents thereof. Thus, it is intended that the scope of the systems disclosed herein 
disclosed should not be limited by the particular disclosed embodiments described above, but 
should be determined only by the scope of the claims that follow. 
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